home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 11⁄3⁄89 / 0017-Re PerformCommand pr-Nov89 < prev    next >
Encoding:
Text File  |  1989-11-03  |  3.5 KB  |  109 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  A33          to A34
  2.  
  3. Item    8064993                         2-Nov-89        18:18
  4.  
  5. From:   ROSENSTEIN1                     Rosenstein, Larry
  6.  
  7. To:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    re PerformCommand problems
  10.  
  11. Curtis,
  12.  
  13. In general, the Commit method must be called before the DoIt method of the next
  14. command.  This is because the Commit method might change the internal data
  15. structures, and the DoIt method might look at those data structures.
  16.  
  17. If you allow the old command to exist while the new command's DoIt is called,
  18. then the application will have to be written to support 2 levels of undo (for
  19. the short time when these commands both exist).
  20.  
  21. You could check whether the last command needs to be committed both before and
  22. after the call to DoIt, but that seems like a awkward way to handle this case.
  23.  
  24. It seems to me that after the TrackMouse is done, the command object should
  25. know whether it is undoable or not.  By the time the mouse button is released,
  26. you should know if the command is undoable or not.  (Ignoring out-of-memory
  27. conditions.)  You can always call a method before TrackMouse exits, which will
  28. set fCanUndo correctly.
  29.  
  30. Exceptions change this.  The command may normally be undoable, but because of a
  31. lack of memory, or some other exception, it won't be undoable in this case.
  32. (For example, you can't allocate the memory to save the current selection.)
  33.  
  34. You could change the value of fCanUndo in the DoIt method, provided
  35. fCausesChange is TRUE.  Then, the last command would be committed, the new
  36. command would be done, and the Undo menu item would be grayed out.
  37.  
  38. The big disadvantage of this is that the user didn't have any say on whether to
  39. go ahead with the command when it wasn't undoable.  I think the best solution
  40. to this is to ensure that the DoIt method can't fail.  This means allocating
  41. any memory it needs to undo before the DoIt method.
  42.  
  43. Larry Rosenstein
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51. Ideally I would like to be able to have the DoIt method set the state of
  52. fCanUndo to the correct value depending on whether the actions of DoIt are
  53. undoable or not.
  54.  
  55. Presently this decision cannot be in DoIt because TApplication.Perform Command
  56. executes in the order:
  57.  
  58. saveCmd :=  command.fCausesChange | command.fCanUndo;
  59.  
  60. IF saveCmd THEN
  61.     CommitLastCommand;
  62.  
  63. ......
  64.  
  65. command.DoIt;
  66.  
  67. IF saveCmd THEN
  68.     BEGIN
  69.     gLastCommand := command;
  70.     command.fCmdDone := TRUE;
  71.     END;
  72.  
  73. Hence if fCanUndo is False then even if Doit sets fCanUndo to TRUE:
  74. gLastCommand is not Set
  75. command.fCmdDone is not set to TRUE
  76. CommitLastCommand is not called
  77.  
  78. because the value of saveCommand is set before DoIt.
  79.  
  80. Why could saveCommand not be computed after DoIt and CommitLastCommand be
  81. deferred?  Perhaps there is some concern that DoIt relies on the
  82. previousCommand having been committed?  I do not know whether this is a more
  83. valid generalization than assuming that DoIt will not change fCanUndo.
  84.  
  85. Is there something wrong with changing fCanUndo in DoIt?  (conceptually at
  86. least, it is wrong now because it does not work)
  87.  
  88. At the least PerformCommand could check
  89.  
  90. { CommitLastCommand would have set gLastCommand to NIL if already executed }
  91. IF gLastCommand <> NIL and command.fCanUndo THEN
  92.     BEGIN
  93.     CommitLastCommand;
  94.     saveCommand := TRUE;
  95.     END;
  96.  
  97. right after DoIt, this would have the effect of enabling changes in fCanUndo
  98. while still ensuring that if the last command's state should be committed
  99. before DoIt it would be.  I am not sure that this is even necessary.
  100.  
  101. Anyone have any thoughts on this?
  102.  
  103. - Curtis
  104.  
  105.  
  106.  
  107.  
  108.  
  109.